This came from an email by Stephen with comments by Scott.
The more technical page on this is:
OTrunk Overlays

> Stephen wrote:
> At this point OTrunk layers are defined with otml. There is work
> going on to support defining OTrunk layers with EMF. A layer
> specifies objects, collections of objects, and their attributes.
>
> An OTrunk instance always has at least one layer which is the base
> layer. Multiple layers can be defined on top of the base layer and
> each in effect stacks onto the layers beneath it. The result is a
> union of all the objects defined in the layers. If the identical
> object is specified in multiple layers then the object in topmost
> layer shadows the object instances in any lower layers and any
> attribute changes are made to only this object. An object that is
> shadowed can't be changed.
That isn't quite accurate. But perhaps it is a good place to start people with.

First some terminology.

This system is very similar to COW (copy on write). COW is used by most virtual machines to maintain a base file system and a delta file system which only contains the changes that a user made. Referencing COW will help some people get a handle on this.

The objects which "shadow" lower objects are called delta objects. The virtual object which is actually used by the view is a composite object.
The composite object looks like a single object to the view. The composite object knows about the base object, any middle layer objects, and possibly a top layer object. A view sees this is a single object which it can read and write properties to. The base object of a composite object could actually be in any layer. This will happen when layer defines a new object which isn't shadowing anything below it.

Now for the inaccurate parts:
Only the top layer can be changed. So a base object, or object in a middle layer, cannot be changed. Saying "an object that is shadowed can't be changed" makes it sound like there has to be a delta object in the top layer otherwise a base object will be changed.

>
> OTrunk has often been used with just two layers: the base layer is
> the activity definition and defines the initial state of the
> activity; the layer on top of the base layer is for Learner data.
> Initially this layer is empty. As a Learner navigates through an
> activity, interacting with rich components, and entering data in
> assessments of various types attributes are changed for many objects.
> When a Learner changes the attributes of an object for the first time
> the original object in the base layer is cloned and the copy is put
> into the Learner layer. Changes the Learner makes are to the object
> in the Learner layer. Objects in the Author layer are not changed.
> When the Learner layer is persisted objects that have been copied
> from the Author layer are saved in a special form that just describes
> attributes that have been changed.

The object is not entiredly copied when a Learner makes a the first change to the object. Instead here is what is happen:

1. An empty delta object is created in the Learner layer
2. The property that the learner changed is copied into this new delta object
3. The change made by the learner is then applied to this copy.

Any later change to the object follows these steps:

1. If the property already exists in learner delta object skip to step 4
2. If the property does not exist in the learner delta object continue
3. Copy the property from the base object to the delta object
4. The property in the delta object is modified.

>
> For example a Question object might contain two attributes: an object
> representing the question and an object representing the answer. In
> the Author layer the answer attribute could be null or have a default
> prompt like:
>
> "enter your answer here ...".
>
> When a Learner enters text into the answer and persists this work the
> difference between the original Question object in the Author layer
> and the new copy in the Learner layer is saved.
>
> The differences are saved in a map (equivalent to a Ruby hash) that
> uses a key to identify the original object and then a list of the
> attributes that have been changed.

Not quite. Yes, the key identifies the original object. The value is the "delta object". The "delta object" is another instance of the same type as the base object. The delta object only has the properties set which are different than the base object. I use the term properties instead of attributes, because attributes have a special meaning in xml. However "properties" have a special meaning in Java. In EMF terms these would be called "features".

>
> This Learner layer has often been referred to as the difference layer
> and this is how our activities have worked. OTrunk does not constrain
> additional layer to only contain differences. A new layer could
> contain entirely new objects that didn't exist in the Author layer.